1. Field of the Invention
The present invention relates to distributed transactional applications such as business process orchestration technology, and, more particularly, to collecting tracking data corresponding to an instance of a business process managed by the technology.
2. Description of the Prior Art
Distributed transactional applications are applications that run in a distributed environment and persist the state of the application data in a server in a transactional manner. An example of a distributed transactional application is business process orchestration technology, which enables the automated management of multiple instances of business processes. A business orchestration product such as, for example, the BIZTALK software application from MICROSOFT corporation of Redmond, Washington allows a user to quickly design, define, and deploy automated business processes that span programs, technologies, platforms, and business partners. For example, a user may create a business process corresponding to the process of determining whether a borrower is approved for a loan. The business process may include the steps of receiving a loan application, sending for an appraisal, receiving an appraisal, sending for a credit history, receiving a credit history, and obtaining final approval, among other things.
For each instance of a process, data corresponding to the state of the instance is stored by a database. When the state of an instance is to be changed, a server performs an operation to modify the data in the database corresponding to the state of the instance. For example, the database may store state data indicating that, for an instance corresponding to the loan application of Jim Smith, a credit reporting agency has been contacted and is in the process of preparing a credit report. When the credit report has been received, a server performs an operation to obtain the state data corresponding to the instance from the database and modify the state data to indicate that Smith's credit report has been received. The server then performs a transaction with the database to store the modified state data for the instance at the database.
One of many advantages of automated management of business processes is that a user can monitor and respond to events occurring across multiple instances. These may include events such as, for example, service start, end, and error information, message in and message out metadata information, and debugging and trace data and message bodies. For each event, corresponding event data is gathered. This event data may be used to alert the business to an error or problem within an instance or across instances or to notify the business of a required action or response. Additionally, detailed event data may be used to compile a comprehensive report on the history and real-time state of any instance of a business process. Thus, it is important that business process orchestration technology provide detailed event data in an efficient and reliable manner.
Furthermore, it is often desirable to analyze and manage event data in a format that is easily comprehended and manipulated. A user may wish to analyze event data according to various attributes corresponding to the events. These may include attributes such as, for example, the type of event, the time at which the event occurred, and the instance to which the event corresponds. In addition, a user may wish to create hierarchies within each attribute. For example, a user may wish to analyze events according to the time at which each event occurred and to group each event according to the date on which it occurred. Data grouped according to date may also be sub-grouped according to, for example, the hour on which it occurred.
Business orchestration technology generally collects event data during the course of performing an operation to modify state data corresponding to an instance of a process. In existing technology, event data is committed to storage at the database upon its collection. A drawback of committing to store upon collection, however, is that a single operation may fail multiple times before the operation succeeds. This is because a server may, for example, crash or lose its connection with the database before the operation is fully performed. Upon failure, the operation is typically transferred to another server which again attempts to successfully perform the operation. Thus, event data corresponding to a single event may be collected multiple times by different servers and stored multiple times at the database. Multiple storage results in multiple data entries for a single event, thereby creating several “false” error alerts or “false” entries in a process report or history.
Existing technology is also limited in that it does not enable a user to select the events corresponding to which he or she wishes to collect data, thereby filling the database with irrelevant and/or unwanted event data. Thus, the user is forced to disregard unwanted alerts and to manually filter out unimportant events from a report or history. Furthermore, existing technology does not enable event data to be analyzed and managed in a format that is easily comprehended and manipulated. In existing business process orchestration technology, event data is stored in a serialized data stream that is not formatted for analysis according to the attributes of the event data.
Thus, a need exists in the art for a system and method for collecting and storing event data from distributed transactional applications that commits event data corresponding to an operation on an instance of a process only after the operation on the instance succeeds. Furthermore, a system and method is needed that enables a user to collect data corresponding to events that are pre-selected by a user and that presents the event data in a format that enables users to easily analyze the data.